home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 4149 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB
  1. Path: diku.dk!null
  2. From: null@diku.dk (Niels Ull Jacobsen)
  3. Newsgroups: comp.lang.c++,comp.os.ms-windows.programmer.tools.mfc
  4. Subject: Re: Newbie question: default op=
  5. Date: 28 Jan 1996 12:13:40 GMT
  6. Organization: Department of Computer Science, U of Copenhagen
  7. Sender: null@tyr.diku.dk
  8. Message-ID: <4efp9k$3el@odin.diku.dk>
  9. References: <30FEA0B4.4F66@ymi.com> <4ebacl$ca4@waena.maui.com>
  10. NNTP-Posting-Host: odin.diku.dk
  11. X-Newsreader: NN version 6.5.0 #13
  12.  
  13. "Paul A. Billings" <pab@maui.com> writes:
  14.  
  15. >Jeffrey Keays <keays@ymi.com> wrote:
  16. >>I am trying to use the &*%$ MFC collections in some way that will dispose of its contents on destruction.  In 
  17. >>my 2-days and counting of ramming my head repeatedly against this brick wall over something that should be made 
  18. >>'easier' by them, I have this general C++ question.
  19.  
  20. The simple MFC collections (CObList and so on) *will* dispose of their
  21. contents on destruction. All they keep are *pointers* to the elements,
  22. not the elements themselves, and these pointers are properly disposed
  23. of :-).
  24.  
  25. But if you want to have collections with this behaviour, it should be
  26. trivial to add you own, derived from the existing ones. 
  27.  
  28. For the templated collections, it's likewise trivial to derive your own.
  29.  
  30. Remember what the F in MFC stands for - MFC is *not* supposed to be
  31. the final do-it-all library. And collection classes is a particularly
  32. weak field of MFC.
  33.  
  34. >>
  35. >>Why is it making me create operator= functions for assignment of the same type (or instance / reference of the 
  36. >>same type).  The class I'm trying to assign has no pointers or anything that would require special handling.  
  37. >>Why do I have to write stupid things like
  38. >>
  39. >>class foo {
  40. >>    int data1;
  41. >>    double data2;
  42. >>    CString data3;
  43. >>    // ... ad infinitum
  44. >>public:
  45. >>    foo& operator=(const foo &);
  46. >>}
  47. >>
  48. >>foo& foo::operator=(const foo &rhs)
  49. >>{
  50. >>    data1 = rhs.data1
  51. >>    data2 = rhs.data2
  52. >>    data3 = rhs.data3
  53. >>    // ... -- I should not have to write this, it should be ASSUMED 
  54. >>    //        by the compiler if I don't specify otherwise.
  55. >>}
  56.  
  57.  
  58. >Relying on any compiler bit-wise copy is OK if using elemental 
  59. >types, but as soon as you threw CString in there, you 
  60. >complicated things.  You don't want to copy the CString, you 
  61. >want to call CString::operator =().  Sooo, form that 
  62. >standpoint, you *should* provide =().
  63.  
  64.  
  65. >>    joblist.AddTail(Job(p, wfd.cFileName));
  66. >>This is the line in MFC with the complaint,
  67. >>    pNewNode->data = newElement;
  68. >>
  69. >>F:\MSDEV\MFC\include\afxtempl.h(813) : error C2582: 'Job' : 'operator =' function is unavailable
  70.  
  71. >As to why the compiler complains, I'm unsure why it does.  It's 
  72. >supposed to use the default =() if none are specified.  I've 
  73. >been burned by this because often the bit-wise copy is not what 
  74. >you want.  Sorry no help here.
  75.  
  76. CObject has a private operator= (and a private copy constructor)
  77. specifically to avoid this common pitfall. You should *always* write a
  78. copy constructor and/or an operator= if you want to use it. Relying on
  79. the default bitwise copy is *very* dangereous, e.g. for CStrings.
  80.  
  81.  
  82. >Paul
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91. -- 
  92.    Niels Ull Jacobsen, Dep. of CS, U of Copenhagen (null@diku.dk)
  93.    Roenne Alle 3 st.th, 2860 Soeborg, Denmark, tel. +45 39 66 39 86
  94.  
  95.